@joostlek Does this PR look familiar to you? Would you mind reviewing this one as well?

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Splitting will be a problem. Because of the dependency so many had to change. And I even added a lot of new tests. We can probably take more time for this review and keep it as is?

Yes but a dependency change does not have to change the way we fetch data or the amount of sensors. Like if it was only 1 new entity, sure. But in this case this PR does too much

@joostlek Honestly, that review is kinda waste of time. You've seen a few pushes from me + it is draft for a reason. Most of the code will look different.

I think this is rather complete now. Now I've mostly refactored it, I do agree with the other comments that this needs to be split out into multiple PRs.

So, what we first can do here, is make a PR that bump the dependency in the existing integrations and does the bare minimum to get there.

That would mean a PR with a Dependency bump, config entry migration + issue, config flow adjustments, config flow test adjustments, and probably the init tests (which test the migration of the entry + issue raised in case of failure) + diagnostics adjustments.

As follow-up PRs could be:

• Add coordinator
• Add entity description support (+ entity entry migration) for the existing sensor + sensor tests
• Add new sensors
• Add strict typing
• Add quality scale files

With this PR in place, that shouldn't be too much of a task to split out.

After that, I think there are quite a few improvements that can be made upstream in the client library as well. Mostly in terms of error handling. Right now, it just silences all the errors and returns None for those cases. While easy to use, it does cause problem as we won't be able to react on it. For example, how would we know the difference between an connection error or data just not being available? Each of these cases is handled differently in Home Assistant, but we don't have that information.

../Frenck

Extracted part 1, the bump: #131567

Coordinator added in #131574

Entity descriptions support: #131585

New sensors: #131587

Extend tests for Stookwijzer init: #131589

Enable strict typing for Stookwijzer: #131590

Add data description for Stookwijzer config flow: #131591

And the last one:

Record current IQS state for Stookwijzer: #131592

Closing this PR, as everything in here is done in the splitter-out PRs listed above.

../Frenck